Internet Protocol (IP) addresses are names that uniquely identify a device on the Internet. To insure uniqueness, IP version 4 (IPv4) addresses were defined as unsigned 32 bit values, which yield 4.29 billion possible public addresses. Certain organizations were tasked with managing the Internet's address space. Their responsibility is to know who is using specific IPv4 addresses at any point in time. It is also their responsibility to ensure that not more than one entity is using the same IPv4 address at any given point in time. There is one group of IPv4 addresses that do not fall under the jurisdiction of these addressing authorities, those being private IPv4 addresses. There are three categories of IPv4 addresses, which have been reserved for private usage: 10.0.0.0/8 (Class A—16.7M addresses), 172.16.0.0/16 (Class B—65.5 k addresses), and 192.168.0.0/24 (Class C—256 k addresses). These addresses may be freely used by any organization. The one disadvantage to using these private addresses is that they may not be used for connectivity over the public Internet, since they could be being used by multiple entities on the Internet.
Unfortunately, the current number of addresses allowed under IPv4 is not enough for the explosive growth of the Internet. One solution to the problem of address scarcity is to use a new addressing scheme. IP version 6 (IPv6) allows for the network to have 128 bit Internet addresses, which yield 34*10^38 possible addresses.
While this is a great improvement over IPv4, implementing IPv6 requires drastic infrastructure overhauls and is not a feasible short-term solution (all future references to IP will imply IPv4).
As a result of the lack of sufficient IP addresses, and the use by many enterprise networks of the private address space within the enterprise network, is that most enterprise networks make use of IP addresses that overlap with addresses in other enterprise networks or even within the virtual private network of the enterprise itself. Virtual private networks (“VPNs”) and virtual local area networks (“VLANs”) were developed to allow companies with multiple physical locations to create a single enterprise network that is transparent to the user. This is accomplished by the enterprise turning over much of the network infrastructure to carriers, such as MCI, AT&T, Southwestern Bell, etc., who connect the remote locations across their own private networks.
To make a VPN, or VLAN (reference to one will hereinafter imply a reference to the other) work since there can be overlapping IP addresses used among the different VPNs being hosted by the carrier or even at the individual physical locations, information identifying the particular VPN being used must be added to the layer two information inside the packet which includes the source address and port information. In order, however for the private addresses to be used across the public internet (“Internet”) Network Address Translation (NAT) and Network Address Port Translation (NAPT) must be used. These functions provide the mechanism to translate private IP addresses to public IP addresses for Internet connectivity.
There are two methods of performing address translation: NAT and NAPT.
NAT performs a 1-to-1-address mapping, for example:
Internal IPExternal IP10.10.108.7065.24.212.70
NAT was developed solely for routing and security purposes where two or more IP addresses cannot be represented by a single network/subnet mask if they are not contiguous. This necessitates more than one route entry to describe the network. If the operator owns the non-contiguous space but does not wish to readdress the network they can use NAT to make the networks appear contiguous. This would allow the route entries to be compressed to a single subnet entry. One attribute of NAT is the hiding internal IP addresses. Since NAT provides translations on all private IP addresses, they will never be exposed to the outside world through the IP header. Some network operators use this as a security mechanism and can be called topology hiding.
The issue of address scarcity is addressed with NAPT. NAPT allows many private IP addresses to be represented as a single public IP address. Network owners must still own public IP addresses, but they can drastically reduce the number of public IP addresses they must own by using a NAPT device in their network. A NAPT device can typically be found where the private network is connected to a public router interface. A NAPT device usually is assigned with one or more public IP addresses. The NAPT device will use these public IP addresses to translate all of the private IP addresses.
Most IP traffic is in the form of request/response protocols, a client asks for some information and a server responds with the information in question. NAPT devices use this behavior for the address translation operation. The NAPT operation can be described as follows:                1. client sends request,        2. client request gets source IP address and port translated by NAPT device,        3. server responds to request by sending packets to IP address and port assigned by NAPT device.        4. NAPT device receives response and translates the destination IP address and port to the proper private IP address and port, and finally the client receives response and renders information to the user.        
A NAPT device must provide translation for both the request and the response packets. A table is used to maintain the translation information. The NAPT translates the request packet and then stores the external IP and port combination used in the table. Response packets are then indexed against this table in order to find the actual internal IP address and port combination, for example:
Src IPDst IPSrc PortDst PortExt IPExt Port10.10.108.8012.14.128.71401238065.30.128.71002210.10.108.71212.24.30.12101128065.30.128.710023
Protocols that include IP address and port information in their message payloads can be adversely affected by the use of NAPT. There are several VoIP protocols that are designed with two main components: signaling and bearer. These protocols are H.323 and H.248, Media Gateway Control Protocol (MGCP) and Session Initiation Protocol (SIP). The signaling protocol is a separate session from the media, or voice, stream and includes in its payload (as opposed to its header) an IP address and port destination of where to send the media stream while the media (voice) will be carried using Real Time Protocol (RTP). Since most NAPT devices do not look at, much less alter, the contents of the IP payload, the indicated IP address and port for the media stream contained in a signaling packet will be ignored by the NAPT device and the media will not be able to pass through the device.
In addition to NAT/NAPT devices, Firewalls also present a problem for peer-to-peer communications such as VoIP. Firewalls provide security for computer networks by filtering out malicious traffic. There are two types of filtering methods: static rules that are called Access Control Lists (ACL), and request derived rules. A standard firewall will implicitly deny traffic. In order for a packet to cross a firewall it must match an allow rule in the firewalls filter rule set. The ACL is a user-provisioned rule that specifies the endpoints that are allowed to communicate. The following ACL shows two entries that could be provisioned to allow traffic between the indicated IP addresses:
Src IPDst IPSrc PortDst Port65.24.212.70212.24.30.12*5060212.24.30.1265.24.212.705060*
Request derived rules are more explicit than ACL rules. A request-derived rule works in a similar manner as NAPT. The firewall has a trusted and un-trusted side (private and public side). These rules are generated by protocol requests that are initiated from the trusted side. A signature (IP address and port information) is stored in a table. Packets that arrive on the un-trusted side are assumed to be responses to requests. If a signature in the table corresponds to the packet, then the packet is assumed to be trusted and is allowed to cross the trust boundary. Each entry also contains a timestamp of the last activity. The signature will be removed from the table if the timestamp becomes older than a predefined amount of time (1-5 minutes).
Request derived rules present similar problems to those encountered with NAPT devices. Again, a network device makes the assumption that all traffic is client-server and will be initiated from a particular side of the device. With VoIP as a peer-to-peer protocol it will not work properly in this environment. A signaling packet, which originates from the un-trusted side, will not match a request-derived rule. ACL(s) can be used to manage inbound signaling, but scale issues can affect the manageability of such a solution and create a large security issue. The largest issue arises from the media that is sent from the un-trusted side of the network. The information that would be used to make a signature for this packet was contained in the payload of a signaling packet that crossed the firewall. Signatures are only generated on information in the header of the packet. Since the IP address and port information are encoded within the payload, a signature will never be created. ACL(s) cannot easily solve this problem, because the ports used for media traffic are dynamically assigned.
Based on the traditional operation of NAT/NAPT devices and the use of private IP addresses in layer two tunneling protocol networks like VPNs and VLANs, real time multimedia communications, especially those that include address information in the payload cannot work across multiple VPNs or VLANs, and cannot connect to a routed IP network such as the public Internet.
Accordingly, what is needed is a method and device for resolving the conflict of overlapping private IP addresses across multiple layer two tunneling protocol networks and to the public IP network.